The Session Initiation Protocol (SIP) is one of several protocols that may be used with the Internet Protocol to support Internet Telephony applications. The SIP specification is defined in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 3261, dated June 2002; the disclosure of which is incorporated herein by reference in its entirety. SIP is an ASCII protocol that facilitates the formation, modification and execution of communication sessions between individual or multiple participants or between networked endpoints, which are referred to as SIP Enabled Devices, User Agents or simply SIP endpoints. The participants may be live, such as videoconferencing clients, an automation component, such as a voicemail server, or a device that can interact in a similar manner. Various interaction types may be incorporated in these communications, including peer-to-peer or multipoint communication. Additionally, users generally possess an address that simulates an email address for identification and location purposes.
Of increased importance in for the SIP protocol is the back-to-back user agent (B2BUA). A B2BUA is a SIP based logical entity that can receive and process messages (such as INVITE) as a SIP User Agent Server (UAS). It also acts as a SIP User Agent Client (UAC) that determines how the request should be answered and how to initiate outbound calls. In the current SIP specification, a B2BUA must typically maintain a SIP dialog state and must participate in all requests sent on the dialogs it has established to process messages properly. However, the current IETF SIP specification (RFC 3261) does not contain any recommendations on how a SIP back to back user agent (B2BUA) may keep a SIP dialog state, thereby leaving this decision to an implementer. As a result, a typical B2BUA maintains a SIP dialog state by storing necessary data locally or remotely for the duration of the SIP dialog. Disadvantageously, storage of the dialog state often requires significant amounts of data under heavy load and complicated mechanisms for data synchronization and recovery in the case of a B2BUA failure.
Therefore, it would be desirable to have a method and system for providing a stateless B2BUA.